A blockchain may be used as a public ledger to store any type of information. Although, primarily used for financial transactions, a blockchain can store any type of information including assets (i.e., products, packages, services, status, etc.). A decentralized scheme transfers authority and trust to a decentralized network and enables its nodes to continuously and sequentially record their transactions on a public “block”, creating a unique “chain” referred to as a blockchain. Cryptography, via hash codes, is used to secure an authentication of a transaction source and removes a central intermediary.
Software applications are crucial components to most organizations' day-to-day operations. The software applications should be operating at all times and even the smallest amount of downtime could be catastrophic. At the same time, there has been a shift towards remote (cloud) computing where individual machine uptime is not guaranteed. Currently, the most popular method of keeping applications highly available is clustering the application and running multiple instances of it on different machines. The replication of the application permits for some of the application instances to fail without causing the application to fail, thus providing a layer of redundancy. The instances of the application cluster that are still running keep the application running. Ideally, this operation is performed without any adverse effects on clients accessing the application.
However, one concern with the current system is the managing of the cluster logic among the nodes in the cluster. The management of the cluster should be dynamic to account for changes in the state of any of the cluster members. This is usually performed in an application specific manner, or by a third party management cluster. It is difficult to manage consensus in a cluster when network partitions and failures are expected to occur. Each software application that implements its own cluster management logic has to overcome this problem. In the case of third party applications used to monitor/manage the cluster, there is now an additional failure approach for the application. For example, if the management cluster that holds the state of the application goes down, the application also goes down, even if none of the instances of the actual application go down. Additionally, that management application must be clustered, and undergoes the same problem as to whether it manages its own clustering logic, or whether it uses another management cluster to manage its own clustering. This would lead to a never-ending chain of management servers, or management clusters managing themselves, which is the problem they were designed to solve in the first place.